過去十年,「測試人員要不要學寫程式」這個問題吵不完。吵的人沒發現,問題的前提在 2024 年之後已經改變了:學自動化的門檻,從「會不會寫程式」變成「會不會描述需求」。而後者,正是你每天在做的事。

以前卡在哪裡

很多測試人員試過學自動化,大多止步在同一個地方:程式語法。買了 Python 或 JavaScript 的課,學了變數、迴圈、函式,三個月後還在寫練習題,離「寫出一個能測自己產品的測試」還很遠。不是不夠努力,是傳統學習路徑把最枯燥的部分放在最前面——你得先啃完語法、記住 API、理解框架,才碰得到第一個真正有用的測試。多數人的動機撐不到那一天。

AI coding 工具改變了順序

Claude Code 這類工具做的事情很單純:你用中文描述想測什麼,它產出程式碼、執行、看結果、修正。整個「寫、跑、修」的循環由它代勞。這代表學習順序可以倒過來——第一天就先有一個會跑的測試,再從這個真實案例回頭理解程式在做什麼。

圖 1:學習路徑的轉變——門檻從最前面移到了過程中

注意,這不是說你永遠不需要懂程式。這個系列後面會花很多篇幅教你「看懂」AI 產出的測試,因為看不懂就無法判斷它測得對不對。差別在於:理解程式變成了在真實案例中逐步累積的事,而不是入場券。

你的手動測試功力,正是 AI 最需要的輸入

和 AI 協作寫測試,品質取決於你給它的輸入。而測試人員的核心技能,恰好就是產出這些輸入的能力:

圖 2:手動測試技能與 AI 協作能力的對應

設計測試案例的功力,決定你能不能把需求描述清楚;等價類劃分和邊界值分析,直接變成資料驅動測試的參數;重現缺陷、精準描述現象的習慣,讓你把錯誤訊息丟給 AI 時能提供對的脈絡;領域知識則讓你有能力判斷——AI 產出的測試通過了,但它驗證的東西到底對不對。

換句話說,開發者學自動化測試,強項在程式、弱項在測試思維;你正好相反。而 AI 補的恰好是程式那一塊。

誠實說,也有需要小心的地方

AI 產出的測試會跑、會過,不代表它測得對。一個沒有斷言的測試永遠是綠燈;一個斷言錯誤的測試會給你虛假的安全感。這是整個系列反覆會回來的主題:自動化測試的價值不在「有沒有」,在「能不能抓到問題」。